There is increasing interest in moving control and intelligence from individual switching, routing, and bridging network nodes to a fewer number of controller nodes. Such networking architectures will be referred to herein generally as centralized control plane networking architectures and are exemplified, for example, by a software-defined network (SDN). An SDN is one example of a network architecture wherein a forwarding plane (sometimes referred to as a data plane) and a control plane, which are conventionally implemented in a single network node, are separated and implemented in two distinct network nodes. Such distinct network nodes may be referred to as a datapath node and a controller node, respectively. An example of an SDN architecture, or specification, is the OpenFlow Switch Specification, version 1.4 (“OpenFlow”).
Theoretically, by separating the forwarding function and the control function into different network nodes, multiple relatively inexpensive datapath nodes may be coupled together and controlled by a single controller node, resulting in a lower overall network cost. Another potential advantage of a centralized control plane networking architecture (CCPNA) is that a single controller node can be more easily programmed to implement new network functionality than would be possible by programming multiple conventional network nodes that combine the control plane and the forwarding plane, thereby simplifying the implementation of additional networking functions in the network.
When a new flow between a source node and a destination node is originated in a CCPNA, an ingress datapath node typically informs the controller node about the new flow so that a path through the network may be determined. The controller node determines an appropriate path through the network, and the controller node then sends packet-forwarding commands to the datapath nodes in the path so that each datapath node can install a flow entry into a flow table that pertains to that particular flow, and indicates where packets associated with the new flow are to be forwarded. This path setup process takes time, relatively substantial controller node processing, and network bandwidth, but provides high-granularity routing through the network.
In some environments however, such as a service provider environment, the number of new flows that are continually initiated may be prohibitive to setup individually. To solve this problem, the datapath nodes may utilize one or more wildcard, sometimes referred to as aggregate, flow entries that group, or aggregate, what could be identified as many separate flows into a single flow entry. For example, an aggregate flow entry may direct that any flow initiated from any media access control (MAC) address, and/or which are destined for any MAC address, be forwarded through a certain port of the datapath node, without a need to communicate with the controller node.
Aggregate flow entries thus reduce communications between an ingress datapath node and a controller node, and reduce the processing requirements of the controller node, but at a loss of flow granularity. The loss of flow granularity can be undesirable however, for other purposes, such as when measuring path performance metrics. Path performance metrics, such as packet loss metrics, or packet delay metrics, become difficult or impossible at a desired level of granularity when multiple independent flows are aggregated together. For example, because each datapath node in a network may have different aggregate flow entries, as well as different non-aggregate flow entries, some flows that are part of an aggregate flow at an ingress datapath node may be split off from the aggregate flow prior to an aggregate flow entry at an egress datapath node, rendering many path performance metrics between the ingress datapath node and the egress datapath node meaningless.
One solution to this problem is an active measurement mechanism that injects trains of probe packets between two datapath nodes. However, such active measurement mechanisms increase traffic on the network, and require that at least some of the datapath nodes include active measurement functionality.
Known passive measurement techniques rely on the datapath nodes providing information about individual flows to the controller node, including, for example, messages from the datapath nodes when a flow is removed from a flow table. However, such messages are not generated when flows are aggregated via aggregate flow entries, and thus, such techniques are not useful for aggregate flows. Maintaining the scalability and flexibility provided by aggregate flows, while still retaining the ability to gather performance measurement metrics on a more granular level would be desirable.
Another solution involves devolving every flow, and then informing the controller node about only those flows whose traffic exceeds a predetermined threshold. However, if the predetermined threshold is set too low, a great number of flows may be individually processed, reducing the advantages of aggregate flows. Moreover, there are no disclosed mechanisms for automatically providing flow performance metrics when a flow is terminated.